XSSすればCookie内のSession IDを知らずとも攻撃できる
XSSがある場合、Cookieに入れていても攻撃が可能になる
tl;dr
XSSがあった場合に、
ちゃんと指定すれば、Cookieの内容は攻撃者には伝わらない
しかし、Cookie内のSession Idなどを使ったrequestは実行できる
そもそもの攻撃者の意図は、
Session IDを取得すること、ではない
Session IDを取得することは、その先の別の目的のための手段に過ぎない
例えば、
userのpasswordを任意に変更する
userの個人情報を得る
etc.
Cookieのoptionなどを厳格にしている場合でも、XSSがあれば
たしかに、Cookie内のSession IDを取得することは防がれるが、
その先の目的は達成できてしまう
そのため、Session IDをCookieで取り扱うのは安全かという問いは、否、となる
Set-Cookie HeaderにはsecureにCookieを扱うために以下のような属性がある
指定したHost自身とそのsub domainに対してのrequestのみCookieを付与する
HTTPSなどのsecureな通信経路を使用した場合にのみCookieを付与する
JSからCookie内のデータにアクセスできなくする
requestの発行元と、宛先がSameSiteである場合にのみCookieを付与する
こういった属性を正しく使おうとも、XSSがある場合は攻撃できる
攻撃の例
userになりすまして、passwordを変更する攻撃を行う
この動画でも同じ例が使われているmrsekut.icon 登場人物と前提
攻撃対象サイトS
XSSできる脆弱性がある
Set-Cookieの属性は厳格になっている
被害者A
Sの利用者で、既にSにloginしている状態である
つまり、Session IDがCookie内に入っている状態である
攻撃者X
Aのpasswordを、例えばhogeに変えたい
Xは、SにXSSを仕込んだサイトを用意し、Aに訪問させる
訪問した瞬間に、Sに対して、passwordをhogeに変更するrequestが投げられる
攻撃完了
Xは、Session IDの具体的な値を知らないが、Aがlogin状態であることを利用して攻撃ができた
XSSなので、「passwordを変更するreqeust」は、正規のサイトSからserverに送られる
これは、SameSite
これは、browserが勝手にCookieを付与する
通信経路が、secureだとかは無関係
要は、XSS攻撃が可能な攻撃者はそもそもCookieの中身のSession IDを欲しがらない
具体的なSession IDを奪取することが、攻撃の割に合わない
Sessionが切れていたら使い物にならない
The most obvious reason is that XSS attacks, although could be targeted, are not instant, like traditional buffer overflow attacks where the attacker point the exploit to a remote location and gain access right away. For an XSS attack to be successful, sometimes it is required a certain period of time to pass until the victim opens a link or do something else. ref the attacker point the exploit to a remote location and gain access right awayの部分の意味がわからない #?? 参考
HttpOnlyを指定してもXSSがあれば危険であることを知っておこうねという主張
https://www.youtube.com/watch?v=4JREwhSC2dQ
実例があってわかりやすいmrsekut.icon